A transmit opportunity (TXOP) is a sequence of frames (and their respective acknowledgements) transmitted serially, immediately following a single successful contention-based channel access attempt, as for instance that prescribed by the IEEE 802.11e standard. All TXOP frames other than the first are transmitted contention-free as the channel has been reserved for their transmission by previously transmitted frames. Each node hearing the transmissions sets its NAV timer according to the expected transmission duration advertised in these frames and refrains from transmitting until the timer expires. There are two options for setting the NAV for a TXOP. One is referred to as ‘frame-by-frame’ NAV setting wherein the NAV is extended with each frame/acknowledgement. The other one is referred to as ‘full’ NAV setting wherein the RTS/CTS indicate the entire TXOP duration. In the second case, if the TXOP duration is overestimated, it is desirable to make the channel available for use by other nodes. NAV clearing must be done in a way that respects the transmissions and reservations made according with the medium access control protocol.
Conventional wireless networks may utilize, among other, the IEEE 802.11 DCF/EDCA single-channel Protocol and the Common Control (CCC) multi-channel Protocol for medium access control. Both protocols can transmit frames in a TXOP.
The CCC protocol is a MAC protocol that extends the IEEE 802.11 distributed MAC protocol to enable use of multiple channels within a BSS or mesh network. The CCC protocol defines a flexible channel access architecture based on distributed prioritized contention-based medium access. The CCC protocol distinguishes between two logical channel functions, the Control Channel (CC) and the Data Channel (DC). In the description that follows, stations or mesh points observing the CCC MAC protocol are referred to as ‘nodes’. Nodes exchange control and management frames on the control channel. The data channels carry data traffic. Data can be carried also on the control channel.
Reservations for transmission on the various data channels are made by exchanging control frames on the control channel. As extensions of the legacy RTS and CTS messages, the CC-RTS and CC-CTS are used to reserve a data channel for the time it takes to transmit a Transmission Opportunity (TXOP). The particular data channel selected for transmission of the TXOP is indicated in a special field on the CC-RTS/CC-CTS. The CC-RTS/CC-CTS exchange could be defined so that it can reserve multiple data channels, or a data channel and the control channel, for the same time interval. A node keeps track of the length of time for which a channel(s) is reserved in a channel-specific NAV, based on the value of the Reservation Duration field of the CC-RTS/CC-CTS.
Both the forwarding and receiving node maintain a NAV for each usable channel. A node monitors the control channel and keeps track of all reservations made by other nodes to determine the busy/idle status of data channels, and when they will become available. The Reservation Duration field on the CC-RTS/CC-CTS is used to update the NAV for the channel reserved. The CC-RTS/CC-CTS Reservation Duration field is different from the Duration/ID field in the MAC header of the CC-RTS/CC-CTS frames. The latter indicates the length of the CC-RTS/CC-CTS transmission on the control channel. A reservation request is declined if the receiving node deems the requested channel busy, or if all its radios are busy.
The receiving node responds with a CC-CTS within a time interval of length Short InterFrame Space (SIFS). A CC-CTS is sent to indicate acceptance of a channel reservation request. The Reservation Duration field is copied in the CC-CTS sent by the receiving node after adjusting its value. If a CC-CTS is not received, the forwarding node assumes that the reservation request is declined. A reservation is accepted if the data channel indicated in the CC-RTS will become idle within a pre-specified time interval, according to the NAV maintained by the receiving node and if the receiving node has available radios to receive the transmission. Successful receipt of a data traffic transmission is followed by an acknowledgement sent either on the data channel according to EDCA rules or as a group acknowledgment on the control channel.
The CC-RTS frame includes several fields including a source node; a destination node; a source node transmit channel; a duration and a number of frames in TXOP. A CC-CTS frame is used by a node accepting a TXOP. The CC-CTS frame includes several fields including a destination node; a source node; a source node transmit channel; a duration; a number of frames in TXOP; and a Radio Counter. A CC-ACK frame identifies the individual frame in a sequence of frames that were received successfully. The CC-ACK frame includes a destination node; source node; and a TXOP frame receipt status.
Channel Reservation occurs when the source node reserves its data channel for one or multiple frames by sending a CC-RTS frame to the destination node on the control channel, provided the NAV for the data channel indicates it will become idle within a pre-specified time. The Reservation Duration field and number of TXOP frames are set in the CC-RTS. The destination node sends a CC-CTS in response within SIFS. The reservation request is accepted if the NAV for the source node's data channel indicates it will become idle within a pre-specified time, and the destination node has available radios to receive the transmission; i.e. the Radio Counter is non-zero. If the reservation request is accepted by the Destination node, the Reservation Duration field is adjusted and the number of frames in the TXOP is repeated in the CC-CTS sent by the destination node and the CC-CTS includes the number of its radios that remain available to receive traffic—that is the Radio Counter. (The latter is not necessary, but it is useful to other nodes with frames to send to the destination node). If the reservation request is declined by the Destination node, the Reservation Duration field in the CC-CTS is set to 0 and the source node in that case sends another CC-RTS with a Reservation Duration field set to 0. Additionally, the destination node will send a CC-CTS with a 0 in the Reservation Duration field in response to a CC-RTS with a Reservation Duration field set to 0. A CC-RTS frame with a Reservation Duration field set to 0 can be used in general to cancel a TXOP. This is equivalent to sending a CF-End frame or a CF-Poll addressed to self with Duration set to 0 when a single channel is used for control and data in order to clear the NAVs of neighbor nodes.
When all frames in a TXOP are transmitted, the destination node will acknowledge the status of the transmit sequence by sending an acknowledgement, called CC-ACK, on the control channel. The frames received successfully will be identified in the CC-ACK. The acknowledgement will be transmitted by contention.
Aside from these additions and a special form of acknowledgement (which is discussed below), the CCC protocol observes the rules of the distributed random access protocol of IEEE 802.11 and its amendments (DCF and EDCA) for channel access and virtual carrier sensing, although further enhancements can enable better channel access prioritization.
CCC is backward compatible with existing 802.11 technologies. All nodes, that is both nodes using existing 802.11 technology and CCC compliant nodes, can communicate on the control channel through the existing 802.11 MAC protocol. In addition, a node that secures the reservation of a data channel will transmit on the reserved channel only after listening for a period equal to the arbitration inter-frame space to ensure that the channel is idle. This measure is introduced to allow for co-existence of CCC-compliant stations with legacy/independent stations.